Article authored by Francesco Servida

Contributions by Eoghan Casey

It is becoming more common to encounter digital files that must be forensically preserved, rather than the entire device or storage media. 

For example, increasing use of encryption by criminals, especially File-Based Encryption (FBE) devices, is driving the need for logical forensic images. A logical image “captures specific files, folders, cloud artifacts, or mobile data instead of an entire physical disk, offering a forensically sound, compressed alternative to standard ZIP or proprietary logical containers.” 

Logical images are being used to exchange files between different organizations for legal proceedings in a manner that their authenticity, integrity, and provenance can be verified (EU E-Evidence Package, ETSI TS 103 643). 

Logical images are also required to safely collect and preserve loose files that could be provided by witnesses to protect them from unintentional modifications or, with proper chain of custody, guarantee their provenance and integrity. 

Indeed, not all witnesses might agree to a forensic acquisition of their devices, even partially, or the data might need to be retrieved in the field by an investigator not specialized in digital forensic. 

Logical Image Standardization

Although organizations may develop a logical image format to store, document, and exchange, not conforming with existing standards in digital forensics can create problems and potentially render evidence inadmissible in legal proceedings. An open, standardized, logical image format would allow for the development of simplified tools for packaging up the loose files collected, guaranteeing integrity and chain of custody from that moment onward.

Different formats for logical forensic images exist such as the proprietary L01 and Lx01, AD1, and X-Ways Evidence Containers. In 2019, Bradley Schatz introduced AFF4-L, as an extension to AFF4 to support logical imaging, in an open format (DFRWS US 2019 paper and presentation). In 2026, AFF4 became a DFRWS.org supported project (https://dfrws.org/projects/).

Forensic containers based on AFF4-L can be created, read and verified by Schatz’s reference implementation in Python. A set of reference images was also provided.

In 2020, Magnet implemented AFF4-L as the logical format for forensic images of remote endpoints for their tool “Magnet Axiom Cyber” albeit in a slightly different and incompatible version. Currently, Magnet Axiom is unable to open AFF4-L reference images, and vice versa the reference implementation pyAFF4 could not open AFF4-L images created by Magnet Cyber, requiring workarounds.

Container Hashes

To fully guarantee the integrity of the content stored in the forensic image and allow verification of the container at later stages, and especially when explicitly challenged, practitioners rely on a combination of proper handling procedures and strong documentation.

Indeed, the use of a forensic image by itself is not enough, as a malicious actor could easily repackage the forensic image after tampering. This is especially easy with open or reverse engineered formats.

To this end, generally a single “container hash” is recorded by the practitioner in their documentation. Systems relying on private and public blockchains have also been proposed, to prevent the hashes themselves from being changed at later stages (Burri et al, 2020, Jaquet-Chiffelle et al, 2020).

While AD1, L01 and Lx01 provide a container hash, AFF4 in its published implementation currently does not.

This is not to say that AFF4 does not have a mechanism to ensure integrity of data; currently AFF4 can record hashes for each segment stored in the container, alongside additional metadata for the segments, such as timestamps and original names or paths. However, the hashes are “per file/segment” and as such are useful to verify that no corruption happened. With the current setup, to prove that no tampering occurred, practitioners would need to store each file hash in their documentation, which for obvious reasons would be unwieldy when handling anything other than a small number of files.

To prevent tampering and ensure proper chain of custody in a simpler way, this article proposes to introduce a container hash for AFF4 format. 

Such container hashes are defined as the hashes (multiple algorithms can be used on the same container) of the “information.turtle” file, calculated after all files/segments have been added to the container and the metadata written in the “information.turtle” file.

The container hash can then be recorded in the AFF4 container as a separate file: “container.hashes.” This file can provide an easy way to retrieve the hash locally, similarly to how AD1/E01 containers also store the hash value itself. The file can be structured as a JSON dictionary with the algorithm name as key and the hexadecimal hash as value.

The hash could afterwards be stored externally in the Investigator’s notebook, Chain of Custody Forms, Evidence Management systems or even following a secure ledger approach, as proposed by (Burri et al., 2020, Jaquet-Chiffelle et al, 2020).

Generating and storing such container hashes allows investigators and courts to later easily verify that the container they are presented with is not corrupted (integrity) and has not been tampered with since it was generated (authenticity).

This can be achieved by chaining the following steps:

A. Retrieve the data for each file/segment stored in the container, calculate the bitwise hash(es) for it and compare with the hash(es) stored in the information.turtle file for the specific files/segments.

• A hash difference at this stage would indicate data corruption (eg. failed transfer/bitrot) or incomplete tampering

B) Calculate the bitwise hash(es) for the information.turtle file and compare to the hash(es) stored in the container.hashes file.

• A hash difference at this stage would indicate data corruption (eg. failed transfer/bitrot) or incomplete tampering.

C) Compare the hash(es) stored in the information.turtle file with the hash(es) stored in the investigator’s notebook/evidence management system/chain of custody forms…

• A hash difference at this stage would indicate tampering, that the wrong container is being examined or an error in the initial documentation of the hash.

A custom implementation of pyAFF4 with the proposed changes is provided here (see specific modifications) and is currently integrated in the tool Gemino.

Extending AFF4 with container hashes in this way allows for a simple, yet needed, functionality for AFF4 containers without impact to existing tools supporting AFF4 as the additional container.hashes file can be simply ignored by tools not yet supporting this functionality.

Large scale adoption of AFF4 and especially AFF4-L will benefit from the existence of a single container hash for investigators to more easily record and verify integrity of collected forensic images.

Next Steps

The implementation proposed in this article reflects the changes made to the AFF4 library fork in use, and published, by Gemino over the last year.

Schatz recently published a draft proposal of updates to AFF4-L specification specifying, between other changes, a container hash. In the draft specification the container hash is equally defined as the hash of the “information.turtle”; the main difference from the above proposal resides in the naming of the file, “information.turtle.hashes” instead of “container.hashes” and the data being stored using RDF instead of being serialized with JSON.

While the technical specification currently differs in those details, it is important to note the convergence of the approach to the container hash, and consensus on the structural approach. 

Going forward, as the standard solidifies we propose to follow the technical approach by Schatz to ensure uniformity in naming and how data is structured inside AFF4-L containers.

To collaborate on implementing, updating, and adopting the standard, join the AFF4 Working Group: https://groups.google.com/g/aff4-wg